home *** CD-ROM | disk | FTP | other *** search
/ Acorn Risc Technologies StrongARM CD-ROM / Acorn Risc Technologies StrongARM CD-ROM.iso / ftp / documents / appnotes / 231_245 / 243c / Text
Encoding:
Text File  |  1993-11-25  |  27.9 KB  |  664 lines

  1. -----------------------------------------------------------------------------
  2. 9th March 1992
  3. -----------------------------------------------------------------------------
  4. Support Group Application Note  Using the Software Protection Scheme in a
  5. Network environment 
  6. Number: 243  
  7. Issue:  1.0
  8. Author: CAS/DM
  9. -----------------------------------------------------------------------------
  10.  
  11. Developer's Notes: 
  12.  
  13.  This application note will enable the reader to understand and hence
  14. correctly identify the behaviour pattern of the Software Protection Scheme
  15. (SPS) in the context of a network environment. It will achieve this by
  16. describing the operation of the SPS with particular reference to the
  17. installation of Advance on network filing systems. Guidance on overcoming
  18. filing system specific problems will also be offered. The mechanisms
  19. described here are deliberately generic and can be applied to other read
  20. only filing systems as they become available.
  21.  
  22. -----------------------------------------------------------------------------
  23. Applicable Hardware: 
  24.  
  25. All Archimedes
  26. All Fileservers
  27. Nexus
  28. NetGain
  29. AppFS Software
  30.  
  31. Related Application Notes: 
  32.  
  33. None
  34.  
  35. -----------------------------------------------------------------------------
  36. Copyright (C) Acorn Computers Limited 1992
  37.  
  38. Every effort has been made to ensure that the information in this leaflet is 
  39. true and correct at the time of printing. However, the products described in
  40. this leaflet are subject to continuous development and improvements and
  41. Acorn Computers Limited reserves the right to change its specifications at
  42. any time. Acorn Computers Limited cannot accept liability for any loss or
  43. damage arising from the use of any information or particulars in this
  44. leaflet. ACORN, ECONET and ARCHIMEDES are trademarks of Acorn Computers
  45. Limited.
  46. -----------------------------------------------------------------------------
  47. Support Group
  48. Acorn Computers Limited
  49. Acorn House
  50. Vision Park
  51. Histon
  52. Cambridge
  53. CB4 4AE                                                  
  54. -----------------------------------------------------------------------------
  55.  
  56. Advance is the first application which utilises the Software Protection Scheme (SPS) which has been developed by Acorn. It is available for use by any software developer who wishes to discourage the use of unauthorised copies of a particular software title.
  57.  
  58. The underlying mechanisms used by the SPS are, by necessity, complex, but Acorn has made every effort to ensure that the installation procedure is as simple as possible.
  59.  
  60. In order to achieve this Acorn has striven to present the user with a simple, prompted, installation procedure. This has proved unobtrusive when coupled with a single user licence. Problems have occurred with multi-user site licence packs, particularly when linked to filing systems which can be configured, by whatever means, to be a read only media. Typically problems have manifested themselves as either continual requests for Program disc 1 or the appearance of an unauthorised use warning message on the client station(s).
  61.  
  62. This application note will provide guidence on installing Advance on network based filing systems including installation on read only filing systems. It will also offer a simplified description of the operation of the SPS for the more inquisitive reader. 
  63.  
  64. The Advance software; an overview
  65.  
  66. In order to provide a large degree of flexibility, both in terms of multi-user functionality and filing system support Advance was designed so that it could appear as a single application or as a series of discrete applications. This was deliberate so that individual user configuration and efficient use of the storage media could be achieved irrespective of the chosen filing system. It is hoped that other software packages which utilise the SPS will adopt similar practices. As a consequence Advance can be separated into 5 component parts or "sub-tasks":
  67.  
  68. **** Graphics 1 ****  The Advance 'Shell'
  69.  
  70. **** Graphics 2 ****  The Advance Graph
  71.  
  72. **** Graphics 3 ****  The Advance Spreadsheet
  73.  
  74. **** Graphics 4 ****  The Advance Wordprocessor
  75.  
  76.  The Advance shell contains the encoded information used by the SPS. This
  77. information cannot be written without the original Advance Program disc 1
  78. being present in the floppy disc drive of the installing machine. Other
  79. applications within the Advance suite cannot be used without first seeing
  80. the shell. The shell holds vital information, without which the remaining
  81. applications will not function.
  82.  
  83.  The Advance shell is used to store information about the single machine or
  84. network fileserver on which it has just been installed. (Note: Once
  85. installed the software always contains information about the first machine
  86. to install it.) This information may take the following form:
  87.  
  88.  In the case of a single machine fitted with an ID chip the unique code
  89. contained in the ID chip will be encoded into the shell and used to identify
  90. the machine each time the copy is run. Single machines without an ID chip
  91. will be allocated an alternative code by the SPS. 
  92.  
  93.  In the case of a network installation the filing system name and the name
  94. of the specific device upon which it has been installed are encoded. The SPS
  95. only recognises filing systems whose path begins with Net or NFS.
  96.  
  97.  The type of licence which has been issued will determine whether the shell
  98. will have "space" for information about the stand alone machine and/or the
  99. fileserver on which it has been installed for use. Each part of this
  100. information can only be written to the copy once, and then, only in the
  101. presence of the original disc. Once these "spaces" have been filled the
  102. shell must be deleted and re-installed from the original program disc. This
  103. would only be of any significance if the name of the fileserver, on which
  104. Advance has been installed, were to change for some reason. Thus, unlimited
  105. copies can be created on fileservers, hard discs, floppies etc from a single
  106. original site licence disc.
  107.  
  108. Installing Advance on a network.
  109.  
  110.  The first thing that must be decided before installing !Advance onto a
  111. network is how you want to store it on the fileserver. There are two
  112. options;  a) Install !Advance in each users own private directory.
  113.  
  114.           b)Install the !Advance shell in each users private directory and
  115. the Advance 'sub-tasks' i.e. Database, Word Processor, Spread Sheet and
  116. Advance GR in a public location which can be read by all users on the
  117. network. 
  118.  
  119.  Although the first of these options offers the most straight forward
  120. installation procedure, it is very inefficient in terms of space used on the
  121. hard disk.
  122.  
  123.  The second option is always to be preferred. The idea of this system is,
  124. when a user logs on, their !ArmBoot file will inform the !Advance shell of
  125. the location of the 'sub-tasks' on the network. This will allow !Advance to
  126. function normally when run. The advantages of this system are that it is
  127. much more efficient on disk space and it will allow each user on the network
  128. to save their own configuration choices as opposed to using a common set
  129. which would apply to everybody on the network. This will allow !Advance to
  130. be configured for each individuals personal needs.
  131.  
  132. If you have decided to follow the first option then follow the steps below;
  133.  
  134.  a1.Run !Advance from Program disc 1. This will enable you to register the
  135. disc for your site.
  136.  
  137.  a2.Logon from a client station on the network as a System Privileged user
  138. and copy the !Advance application into a users directory on the fileserver.
  139.  
  140.  a3.Whilst holding down the SHIFT key, double-click on the !Advance
  141. application. This should open the !Advance window and display the
  142. applications files. Copy !AdvanceWP from the second floppy disc into this
  143. window.
  144.  
  145. **** Grahpics 5 ****
  146.  
  147. Figure 2: The complete !Advance application (including all sub-tasks).
  148.  
  149. a4.Run the copy of !Advance which you have just created.
  150.  
  151. a5.Follow the installation instructions which appear on the screen.
  152.  
  153. a6.Once the installation is complete, it will be possible to duplicate this
  154. fully installed version of !Advance from the directory in which it was
  155. installed into every users private directory.
  156.  
  157. If you have decided to impliment the second option then follow these steps;
  158.  
  159. b1.As (a1) above.
  160.  
  161. b2.As (a2) above.
  162.  
  163. b3.As (a3) above.
  164.  
  165. b4.Move the following files into a publicly accessible area on the
  166. fileserver. !AdvanceDB 
  167.             !AdvanceGR 
  168.             !AdvanceSH 
  169.             !AdvanceWP
  170.  
  171. The remainder of this section will assume that they have been placed in
  172. Net:$.Apps.Advance. The !Advance directory should now look like this;
  173.  
  174. **** Graphics 6 ****
  175.  
  176. Figure 3: The !Advance shell.
  177.  
  178. b5.We need to inform the shell about the whereabouts of the main
  179. applications which it needs.  There are two ways of doing this and you
  180. should select the one most appropriate to your working practices.
  181.  
  182. Method 1.
  183.  
  184. Shift-double click on the working copy of the !Advance application. Load the
  185. file called !Boot into !Edit. Amend the file to read as follows:
  186.  
  187. IconSprites <Obey$Dir>.!Sprites 
  188. Set File$Type_dfe CSV 
  189. Set Advance$Dir <Obey$Dir> 
  190. Set Advance$Apps Net:$.Apps.Advance 
  191. Filer_Boot <Advance$Apps>.!AdvanceDB
  192. Filer_Boot <Advance$Apps>.!AdvanceGR 
  193. Filer_Boot <Advance$Apps>.!AdvanceSH
  194. Filer_Boot <Advance$Apps>.!AdvanceWP
  195.  
  196. Method 2.
  197.  
  198. Insert the following lines into the main client boot sequence if you have
  199. one, or alternatively into each users boot sequence:
  200.  
  201. Set Advance$Apps Net:$.Apps.Advance 
  202. Filer_Boot <Advance$Apps>.!AdvanceDB 
  203. Filer_Boot <Advance$Apps>.!AdvanceGR 
  204. Filer_Boot <Advance$Apps>.!AdvanceSH 
  205. Filer_Boot <Advance$Apps>.!AdvanceWP
  206.  
  207. Using either of these two methods will ensure that whenever !Advance is seen
  208. by the filer it will automatically know where to find its remaining
  209. resources.
  210.  
  211. b6.From the client machine ensure that you are still logged on as a System
  212. Privileged user and run the copy of !Advance you have created.
  213.  
  214. b7.Follow the installation instructions which appear on the screen.
  215.  
  216. b8.Once the installation is complete, it will be possible to duplicate the
  217. installed version of  the !Advance shell from the directory in which it was
  218. installed into every users private directory as shown below.
  219.  
  220. **** Graphics 7 ****
  221.  
  222.  
  223.  Figure 4: Overview of the directory structure after installation of
  224. !Advance. Notes:     In both these examples the path Net::$.Apps.Advance has
  225. been assumed. If you use a different directory structure or change the
  226. structure after installation then you will have to alter this reference
  227. accordingly. 
  228.  
  229.  Management of multiple copies of the Advance shell can be difficult.
  230. Utilities such as NetManage from Suitable Software can assist in this
  231. respect when the copies are stored on Acorn fileservers. Contact Suitable
  232. Software on (0638) 720171 for more information.
  233.  
  234. AppFS
  235.  
  236.  When installing Advance on any application server the !Advance shell must
  237. be separated from the main sub-tasks. The following steps illustrate the
  238. procedure:
  239.  
  240. 1.Run !Advance from Program disc 1. This will enable you to register the
  241. disc for your site.
  242.  
  243. 2.Decide which filing system is to hold the !Advance shell. It may be placed
  244. on one of the following filing systems:
  245.  
  246. on a fileserver whose path begins Net or NFS 
  247. on a local dedicated writable media connected to the Archimedes eg. an ADFS
  248. hard disc an ADFS floppy disc etc, etc
  249.  
  250. If you decide to install the !Advance shell on a local media then each copy
  251. of !Advance will have to be individually installed  for each machine. In the
  252. case of floppy disc based media, each disc will need to be uniquely
  253. identified to the machine on which it was installed. However, as most
  254. application servers utilise the network cable infra-structure it is likely
  255. that there will also be a fileserver present. In these circumstances it is
  256. recommended that the !Advance shell is placed on the fileserver. (See:
  257. Installing Advance on a network.)
  258.  
  259. 3.As (b4) except that the files must be moved into an area of the AppFS
  260. filing system. The remainder of this section will assume that they have been
  261. placed in AppFS:$.Apps.Advance.
  262.  
  263. 4.Make a copy of the !Advance shell on a floppy disc. Do not install this
  264. shell yet. The shell should contain the following files:
  265.  
  266. **** Graphics 8 ****
  267.  
  268. Figure 5: The Advance shell.
  269.  
  270.  5.Taking the floppy disc copy, modify it as described in (b5) above. Ensure
  271. that all filing system references are to AppFS. eg:
  272.  
  273. Set Advance$Apps AppFS:$.Apps.Advance
  274.  
  275. Mark this disc as Modified Advance Shell Master Disc.
  276.  
  277. 6.Now copy the contents of the  Modified Advance Shell Master Disc onto your
  278. chosen filing system as defined in 2 above. 
  279.  
  280. If the !Advance shell is to be placed on a Network then follow steps (b5),
  281. (b6) and (b7) above.
  282.  
  283. If it is to be placed onto a media local to each machine then copy the
  284. contents of the Modified Advance Shell Master Disc onto the media and
  285. install each individual shell in turn, using the appropriate guidelines
  286. provided in the Advance User Guide and/or Release note.
  287.  
  288. The following diagram illustrates the completed directory structure for an
  289. AppFS/fileserver combination.
  290.  
  291. **** Graphics 9 ****
  292.  
  293.  
  294.  Figure 6: The AppFS and fileserver directory structures after installation.
  295.  
  296. NetGain 
  297.  
  298.  The method employed when using NetGain is identical to that used for AppFS
  299. installations. The differences are that the four shell dependant
  300. applications must be placed in the area reserved for use by the NetGain
  301. filing system and that the filing system name specified in the variable
  302. Advance$Apps is amended to specify NetGain.
  303.  
  304. Nexus
  305.  
  306.  Again the mechanism employed is similar to that used for AppFS, but the
  307. file transfer speed and flexibility offered by the Nexus disc sharer enable
  308. the system manager to maintain the individual copies of the !Advance shell
  309. far more easily. A recommended installation method for the Nexus disc sharer
  310. is illustrated below. Changes which are required to enable this to function
  311. for Nexus Networking are also included at the appropriate stages.
  312.  
  313. 1.Run !Advance from Program disc 1. This will enable you to register the
  314. disc for your site.
  315.  
  316. 2.Decide which filing system is to hold the !Advance shell. It is normal to
  317. place it on the Nexus drive 5 but it may be placed on one of the following
  318. filing systems:
  319.  
  320. on a fileserver whose path begins Net or NFS 
  321. on a local dedicated writable media connected to the Archimedes 
  322. eg. an ADFS hard disc 
  323. an ADFS floppy disc a SCSI hard disc etc, etc
  324.  
  325.    If you decide to install the !Advance shell on Nexus drive 5 then each
  326. copy of !Advance will have to be individually installed  for each machine.
  327. In the case of floppy disc based media then each disc will need to be
  328. uniquely identified to the machine on which it was installed. However, as
  329. most application servers utilise the network cable infra-structure it is
  330. likely that there will also be a fileserver present. If user specific
  331. configuration of numerous !Advance shells is required it is recommended that
  332. these are placed on the fileserver. (See: Installing Advance on a network.)
  333.  
  334. 3.As (b4) except that the files must be moved into an area of the shared
  335. Nexus drive 4 filing system. The remainder of this section will assume that
  336. they have been placed in Nexus::4.$.Apps.Advance.
  337.  
  338. 4.Make a copy of the Advance shell on a floppy disc. Do not install this
  339. shell yet. The shell should contain the following files:
  340.  
  341. **** Graphics 10 ****
  342.  
  343.  
  344. Figure 7: The !Advance shell.
  345.  
  346. 5.Taking the floppy disc copy modify it as described in (b5) above. Ensure
  347. that all filing system references are to Nexus drive 4. eg:
  348.  
  349. Set Advance$Apps Nexus::4.$.Apps.Advance
  350.  
  351. Mark this disc as Modified Advance Shell Master Disc.
  352.  
  353. 6.Now copy the contents of the  Modified Advance Shell Master Disc onto each
  354. Nexus drive 5 or your chosen filing system as defined in 2 above. 
  355.  
  356. Install each individual shell in turn, using the appropriate guidelines
  357. provided in the Advance User Guide and/or Release note.
  358.  
  359. 7.Nexus disc sharer:
  360.  
  361.  Take an 800K formatted floppy disc and create on it a directory called
  362. Port_n where n is the number of the port to which the machine is connected.
  363. The port number can be obtained by pressing f12 and typing:
  364.  
  365. *Show Nexus$Portnumber
  366.  
  367. At the command line prompt. Copy into this directory the newly installed
  368. !Advance shell from the private partition. Repeat this for all the machines
  369. connected to the Nexus unit.
  370.  
  371. Nexus networking:
  372.  
  373.  Take an 800K formatted floppy disc and create on it a directory called
  374. Stn<stationnumber> where <stationnumber> is the station number allocated to
  375. the machine. The machines station number can be obtained by pressing f12 and
  376. typing:
  377.  
  378. *help stataion
  379.  
  380.  at the command line prompt. Copy into this directory the newly installed
  381. !Advance shell from the private partition. Repeat this for all the machines
  382. connected to the Nexus unit.
  383.  
  384. When you have finished you will have a floppy disc with a maximum of 12
  385. appropriately named directories, each containing a unique, identifiable,
  386. installed copy of the !Advance shell for each machine connected to the Nexus
  387. unit.
  388.  
  389. 8.If you are using the !Boot application supplied on the shared Nexus drive
  390. simply SHIFT double click on the !Boot application and copy the contents of
  391. the floppy disc which contains the  directories into it.
  392.  
  393. Now amend the boot sequence with the following line:
  394.  
  395. Nexus disc sharer:
  396.  
  397.     *Copy <Boot$Dir>.Port_<Nexus$PortNumber>.* <Work$Dir>.* FRV~Q~C
  398.  
  399.  Most boot sequences supplied on the Nexus disc sharer automatically set the
  400. system variables <Boot$Dir>, <Nexus$PortNumber> and <Work$Dir>. 
  401.  
  402. Nexus networking:
  403.  
  404. *Copy <Boot$Dir>.Stn<Nexus$Station>.* <Work$Dir>.* FRV~Q~C
  405.  
  406.  Most boot sequences supplied with the Nexus networking automatically set
  407. the system variables <Boot$Dir>, <Nexus$Station> and <Work$Dir>. 
  408.  
  409. Now whenever a machine is switched on or reset, the boot sequence will
  410. automatically identify the machine and copy the contents of the
  411. corresponding directory into the private partition. Thus, if students delete
  412. or damage the !Advance shell it is simply a matter of resetting the machine
  413. and letting the boot sequence copy a clean shell over. The appropriate areas
  414. of the directory structure is shown below.
  415.  
  416. **** Graphics 11 ****
  417.  
  418.  
  419.  
  420. Figure 8: Nexus directory structure after installing Advance.
  421.  
  422.  This method can only be recommended when using a Nexus style system
  423. because, whilst it can be made to function on other filing systems it will
  424. increase the boot up time significantly due to the slower data transfer 
  425. rate.
  426.  
  427.  
  428. Trouble shooting.
  429.  
  430.  This section will deal with the remaining installation issues which have
  431. been reported to Acorn since the release of Advance.
  432.  
  433.  The effects of attempting to install Advance on a fileserver without system
  434. privilege access.
  435.  
  436. In this instance Advance will generate the following error message:
  437.  
  438. **** Graphics 12 ****
  439.  
  440. Figure 9: An Advance I/O error box.
  441.  
  442.  Whilst it appears that the original Program disc has developed a disc fault
  443. what has really happened is that an "Insufficient privilege" error has
  444. occurred and been reported as a disc fault.
  445.  
  446.  Solution: Logon as a system privileged user and repeat the installation
  447. procedure again.
  448.  
  449.  The effects of failing to set public read access on all the files in the
  450. Advance shell. 
  451.  
  452.  In the worst case this will have the effect of only allowing the system
  453. privileged user to run !Advance. In this situation if any attempt is made to
  454. run Advance as a normal user it will always prompt for the original Program
  455. disc. Attempting to install the software as a normal user will usually
  456. generate the previous error. Logging on as a system privileged user will
  457. always allow the software to be installed, but any attempt to run it will
  458. cause the SPS to prompt for the original Program disc.
  459.  
  460.  Solution:Logon as a system privileged user and set the access rights for
  461. the whole  application to WR/R.
  462.  
  463.  
  464.  Appendix A: The Software Protection Scheme; an overview
  465.  
  466.  Conceptually we think of the SPS as having a series of "spaces" or "boxes"
  467. which are filled in at the time of installation. In the case of a site
  468. licence version there will be three such "boxes", other licence variants may
  469. have a different number. These boxes hold information about the machine on
  470. which the disc was originally registered, the stand alone machine on which
  471. it can be used and the fileserver from which it can be run. Prior to
  472. installation the Advance shell will have no registration information and
  473. hence these boxes will be empty, thus:
  474.  
  475. Orig Machine ID Machine ID Fileserver ID
  476.  
  477.  
  478.  Figure 10: Illustration of the information held by the SPS before
  479. installation.
  480.  
  481.  When the application software is installed it must be recreated each time
  482. and new, machine specific, information  placed in the appropriate ID "box".
  483. It is vitally important that the application software is copied from the
  484. original program disc each time it is installed. The application will
  485. contain other information which states if the copy on the machine has
  486. already been installed. If it has then the SPS will not allow the copy to be
  487. updated.  Each part of this information can only be written to the copy
  488. once, and then, only in the presence of the original disc. Once these
  489. "boxes" have been filled the application must be deleted and re-installed
  490. from the original program disc. Thus, unlimited copies can be created on
  491. fileservers, hard discs, floppies etc from a single original site licence
  492. disc.
  493.  
  494.  Imagine we have three machines; two with hard discs and one with only a
  495. floppy disc. The following sequence illustrates how the data in the Machine
  496. ID changes with each installation. (For the sake of clarity the data in the
  497. ID chip is fictitiously shown to correlate to the hardware configuration,
  498. and order of installation.)
  499.  
  500. T he user copies the software onto the first hard disc machine. When the
  501. copy is run the SPS will prompt for the original Program disc. The SPS will
  502. read and update the copied software and the program disc with the unique
  503. code stored in the ID chip. This information will be written into the
  504. appropriate ID box. This information will always be carried on the program
  505. disc and copied to any subsequent discs. Once it has been copied, additional
  506. information may only be written once to each ID box in the copy. 
  507.  
  508.  Irrespective of the number of copies made the original Program disc will
  509. now remain unchanged. 
  510.  
  511.  Orig Machine ID    Machine ID    Fileserver ID HDmachine1
  512.  
  513.  Figure 11: Illustration of the information placed on the original Program
  514. disc, by the SPS,
  515.  after the 1st installation.
  516.  
  517.  Orig Machine ID     Machine ID Fileserver ID HDmachine1 HDmachine1
  518.  
  519.  Figure 12: Illustration of the information placed in the working copy of
  520.  the software, by the SPS,
  521.  after the 1st installation.
  522.  
  523.  The software is then installed on the second hard disc machine using
  524. exactly the same procedure.
  525.  
  526.  Orig Machine ID Machine ID Fileserver ID HDmachine1 HDmachine2
  527.  
  528.  Figure 13: Illustration of the information placed in the next working copy,
  529.  by the SPS,
  530.  after the 2nd installation.
  531.  
  532. The data in the Machine ID box now contains the current machine ID chip
  533. value (HDmachine2). Finally the software is installed on a floppy disc based
  534. machine.
  535.  
  536. Orig Machine ID Machine ID Fileserver ID HDmachine1 FDmachine3
  537.  
  538.  Figure 14: Illustration of the information placed in the next working copy,
  539. by the SPS,  after the 3rd installation.
  540.  
  541.  This process can be repeated continuously until the software has been
  542. installed on all the machines. If the copy of the software is deleted then
  543. it will need to be  re-installed from the original program disc. The flow
  544. diagram, provided for reference purposes in Appendix B, illustrates the
  545. sequence of tests which the SPS makes when loading the application to
  546. determine if the copy is authorised or not.
  547.  
  548. Network installation.
  549.  
  550.  Now imagine we wish to use the first hard disc machine as a Level 4
  551. fileserver. To do this we must ensure that the software is aware of the
  552. fileserver upon which it has been installed. To achieve this we simply
  553. ensure that when running the software from the fileserver for the very first
  554. time we do so as a System Privileged user and follow the instructions given
  555. by the SPS. This will ensure that the box which holds the Fileserver ID will
  556. be updated using the network type and the storage media name. In the
  557. following example it is assumed that the network type is Ethernet (or
  558. Econet) and that the fileserver appears on the network under the name
  559. Level4.
  560.  
  561. Orig Machine ID Machine ID     Fileserver ID  HDmachine1     HDmachine1
  562. Net::Level4
  563.  
  564.  Figure 15: Illustration of the additional information placed in the 1st
  565. working copy, by the SPS,
  566.  after the 1st Fileserver installation.
  567.  
  568.  This particular combination of information will allow the same copy of the
  569. software to be run on the local machine which identifies itself, through its
  570. ID chip, as HDmachine1 and on any client machine on the network providing it
  571. is loaded from a fileserver which identifies itself as Level4 on the filing
  572. system called Net.
  573.  
  574.  If installation were required on a FileStore, which identifies itself on
  575. the network by the name FS, then the procedure would involve simply copying
  576. the software from the original Program disc on to the FileStore in the usual
  577. way. The installation is completed by running the software from a system
  578. privileged client machine remembering to follow the prompts given by the
  579. SPS. Using the above example, the information in the SPS boxes after
  580. installation on the FileStore would be:
  581.  
  582.  Orig Machine ID Machine ID Fileserver ID HDmachine1 Net::FS
  583.  
  584.  Figure 16: Illustration of the information held in the next working copy,
  585.  by the SPS,
  586.  after the 2nd Fileserver installation.
  587.  
  588.  As you can see the scheme is quite simple, and with an understanding of
  589. this model it becomes possible to predict the outcome of any given set of
  590. circumstances.
  591.  
  592. Installation on multi-user media which can be write protected.
  593.  
  594.  Consider the installation of the application on a media which during normal
  595. client use is always write protected. In these circumstances the
  596. installation methods described above will always invoke the SPS because you
  597. cannot install the copy from a client machine over the network. Consider
  598. also the circumstances where the network cabling is utilised to load the
  599. application, but the filing system name does  not begin with Net or NFS.
  600. Both these circumstances are possible due to the diversity of filing systems
  601. which are currently available under RISC OS.
  602.  
  603.  An application server such as AppFS does not support any remote write
  604. operations. In these circumstances it has to be installed locally on the
  605. machine which is physically connected to the storage media. This results in
  606. the update of the Machine ID but not the Fileserver ID.
  607.  
  608. Orig Machine ID Machine ID Fileserver ID HDmachine1 AppFShost
  609.  
  610.  Figure 17: Illustration of the information placed in an application, by the
  611. SPS, after installation on an AppFS Server.
  612.  
  613.  When an attempt is made to run the software from a client machine the SPS
  614. will recognise that:
  615.  
  616. the software has been registered.
  617.  
  618. that it has been installed.
  619.  
  620. that it has only been installed for single machine access.
  621.  
  622.  that the client machine ID is not the same as that of the machine on which
  623. it was installed.
  624.  
  625. The SPS will then issue an appropriate message. eg:
  626.  
  627. **** Graphics 13 ****
  628.  
  629.  Different circumstances can generate the same end result. Consider a Nexus
  630. disc sharer which is at the heart of a Nexus network. In this instance the
  631. application can only be updated from the client machine connected to port 1
  632. of the Nexus system. When this has been completed the shared application
  633. area is write protected using the mechanical keyswitch.  This would seem to
  634. overcome the problems described earlier. However, during the installation
  635. procedure the SPS will have examined the path used to update the copy. It
  636. will derive from this that the pathname does not start with Net or NFS and
  637. so will update the shell as if it were a single machine copy. When the
  638. application is run from one of the other client machines the SPS will
  639. generate the unauthorised use warning as before.
  640.  
  641.  This is exactly the same for other shared solutions which have filing
  642. system names other than Net or NFS. Some common examples are given below:
  643.  
  644. AppFS 
  645. AppFS:: 
  646. NetGain 
  647. NetGain:: 
  648. Nexus 
  649. Nexus::
  650.  
  651.  The solution is, broadly speaking, the same for all these and other,
  652. perhaps yet to be developed, filing systems which exhibit the same or
  653. similar features. It involves breaking down the application into its
  654. component parts and storing the SPS component on a different supported
  655. filing system or, if the filing system supports this, on read/write areas of
  656. the same filing system.
  657.  
  658. Appendix B: SPS flow chart
  659.  
  660. **** Graphics 14 ****
  661.  
  662.  
  663.